InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / noop / plans / dod_osi < prev next >

Wrap

Internet Message Format | 1991-07-30 | 29KB

From bradshawg@imo-uvax6.dca.mil Fri Jul 26 15:56:10 1991 Received: Fri, 26 Jul 91 15:56:06 EDT by rivendell.merit.edu (5.51/1.6) Return-Path: <bradshawg@imo-uvax6.dca.mil> Received: from IMO-UVAX6.DCA.MIL by merit.edu (5.65/1123-1.0) id AA12216; Fri, 26 Jul 91 15:53:22 -0400 Message-Id: <9107261953.AA12216@merit.edu> Date: 25 Jul 91 15:07:00 EDT From: "bradshaw, george" <bradshawg@imo-uvax6.dca.mil> Subject: DoD's GOSIP NSAP Addresses To: "skh" <skh@merit.edu> Status: R D E F E N S E I N F O R M A T I O N S Y S T E M S A G E N C Y Date: 25-Jul-1991 02:43pm EST From: George Bradshaw BRADSHAWG Dept: DNSO/DRFD Tel No: 703/487-3029 TO: SKH@MERIT.EDU ( REMOTE ) Subject: DoD's GOSIP NSAP Addresses Susan, Let me introduce myself. I am George Bradshaw and work for the Defense Communications Agency. As chair of the DCA Protocol Standards Steering Group's (PSSG) OSI Registration Authority working group, I have been involved with defining a semantic for a DoD GOSIP 2 NSAP. Dennis Morris, a co-worker in DCA, gave me your name saying you might be interested in a draft of the first product of the working group (see the attachment). The draft is still undergoing review for considerations of policy routing, address space size, hierarchy format, relationship (if applicable) to Defense Message System MTAs, etc. Your comments, technical or administrative, on that draft would be greatly appreciated, especially considering your position with the NSFNET. Thanks. George D E F E N S E I N F O R M A T I O N S Y S T E M S A G E N C Y Date: 24-Jul-1991 05:11pm EST From: George Bradshaw BRADSHAWG Dept: DNSO/DRFD Tel No: 703/487-3029 TO: See Below Subject: DTMP WG 6 Documents Folks, Attached is the final draft of the DTMP OSI Registration Authority Working Group 6 (WG6) "DoD NSAP Semantics and Assignment Concept Under GOSIP Version 2 NSAP Syntax". Please review the parts of interest to your area. There are many aspects of the NSAP assignment which affect DISN, network management, control of network assets, OSI registration authority responsibility within DoD, support of network services (e.g., DMS), structure of information systems using the networks, relationship to transmission systems (e.g., AFNET and MILNET), etc. Any comments would be appreciated before the paper receives wider distribution and undergoes the process of incorporation into our network engineering plans. George Postal Address: EMail Address: Telephone: DISA (Code DRFDS) bradshawg@imo-uvax.dca.mil Comm: 703/487-3029 1860 Wiehle Avenue Von: 364-3029 Reston, Va. 22090-5500 Attn: George Bradshaw Distribution: TO: DTMP-WG6@GATEWAY.MITRE.ORG ( REMOTE ) TO: JONSON@SERVER.AF.MIL ( REMOTE ) TO: JGATEWOOD@CSDAELAN.SSC.AF.MIL ( REMOTE ) TO: NAVYDOMMGR@NARDACVA.NAVY.MIL ( REMOTE ) TO: ISAD17@PENTAGON-BCN.ARMY.MIL ( REMOTE ) TO: ISAD18@PENTAGON-EMH2.ARMY.MIL ( REMOTE ) TO: TFOGLE@HUACHUCA-GIIS.ARMY.MIL ( REMOTE ) TO: BNELSON@BBN.COM ( REMOTE ) TO: JZINKY@BBN.COM ( REMOTE ) TO: DAYJD@P3.AMS.WPAFB.AF.MIL ( REMOTE ) TO: SRA@EDN-VAX.DCA.MIL ( REMOTE ) TO: LORIB@GATEWAY.MITRE.ORG ( REMOTE ) TO: BEACH@DDNUVAX.AF.MIL ( REMOTE ) TO: CAIN@EDN-VAX.DCA.MIL ( REMOTE ) TO: ELLER@OASYS.DT.NAVY.MIL ( REMOTE ) TO: Yuen-Sun Fu ( FUY ) TO: EPG@GATEWAY.MITRE.ORG ( REMOTE ) TO: GROSS@POLARIS.DCA.MIL ( REMOTE ) TO: LATRAILLESL@AFSC-SSD.AF.MIL ( REMOTE ) TO: LAZEAR@GATEWAY.MITRE.ORG ( REMOTE ) TO: LEWALLEN@DDNUVAX.AF.MIL ( REMOTE ) TO: MALIS@BBN.COM ( REMOTE ) TO: Joseph Mensch ( MENSCHJ ) TO: Jim Bennett ( BENNETTJ ) TO: CMILLS@BBN.COM ( REMOTE ) TO: MILLS@OSI3.NCSL.NIST.GOV ( REMOTE ) TO: June Mallory ( MALLORYJ ) TO: Dennis Morris ( MORRISD ) TO: CATHY@GATEWAY.MITRE.ORG ( REMOTE ) TO: POGRAN@BBN.COM ( REMOTE ) TO: PRICE@GATEWAY.MITRE.ORG ( REMOTE ) TO: STJOHNS@UMD5.UMD.EDU ( REMOTE ) TO: John Thomas ( THOMASJ ) TO: TONTONOZ@EDN-VAX.DCA.MIL ( REMOTE ) TO: Sandra Vest ( VESTS ) TO: William Arey ( AREYW ) TO: Tu Nguyen ( NGUYENT ) TO: Nancy Tran ( TRANN ) TO: Ann Tso ( TSOA ) TO: Darryl Henry ( HENRYD ) osi\nsap--05.doc DoD NSAP Semantics and Assignment Concept Under GOSIP Version 2 NSAP Syntax D R A F T July 24, 1991 1. Introduction The Defense Information Systems Agency (DISA), formerly called the Defense Communications Agency (DCA), recognizes the need for guidance in establishing a semantic for the GOSIP Version 2 NSAP used by the Department of Defense (DoD) services and agencies. The DISA also recognizes that outstanding issues, some distantly related to the semantic, will affect the use of any chosen semantic. These issues will be resolved with further research, development and experience. Accordingly, in the spirit of synergy, this paper recommends an interim DoD NSAP semantic. 2. Background The Data Communication Protocol Standards (DCPS) Technical Management Panel's (DTMP) Registration Authority (RA) ad hoc Working Group 6 (WG6) provides a forum in which an NSAP semantic may be developed for DoD. WG6 produced the last draft version of this paper. The paper recommended a semantic and assignment with extensive use of the administrative authority field to support a hierarchical topology and address abstraction. It also defined routing domains in a MILNET-centric manner by embedding the MILNET address in the NSAP routing domain field. The paper did not consider enterprise systems or non-geographically organized concepts in the semantic. These constructs are here reconsidered to take better advantage of the NSAP syntax and routing protocol standards. 3. Issues - How to use transmission networks based on smart multiplexors such as AFNET Transmission networks must be recognized as distinct from routers. The networks become a means of transmission only, unrelated to the activity of a set of routers except to the extent that transmission analysis could make cost effective use of circuits. It may be appropriate to consider transmission as a DoD-wide service with router networks being a single class of transmission subscriber. - The extent to which a router backbone is required Backbones (and to a similar extent regionals) serve two functions: 1) to provide geographical or organizational interoperability between communicating systems, and 2) to support efficient use of bandwidth. Definitions. In the OSI context a DoD backbone would be a routing domain, access to which would be through the Inter-Domain Routing Protocol (IDRP), similar in function to EGP or BGP. Geographical interoperability in this context means interconnecting two geographically oriented domains via a transit routing domain (TRD). A backbone provides a direct service for organizational interoperability when it interconnects two domains which have an organizational (e.g., all Air Force, an enterprise system, etc.) rather than geographic orientation. Case 1. If the DoD chooses to have many separate and small routing domains, then a router backbone could be used to centralize those functions (router and routing data base server) which support the interconnection among the domains. There could be extensive use of the centralized functions. This scheme would be in lieu of an IDRP protocol among the border routers of each of the small domains; rather, IDRP would be used exclusively between the small domains and the backbone domain. Since IDRP is currently not available, the interdomain update functions would be performed with static tables. Case 2. If the DoD chooses to have few large routing domains with little interdomain activity, and intradomain traffic moving largely through circuit networks rather than router domains; then the backbone would be less active. There may be only need to share IDRP activity with a few routers within the large domains. With an effective method of sharing management of the "backbone", a centralized backbone might not be required. Case 3. If in Case 2 there is still extensive interdomain traffic (possibly requiring many interdomain trunks), then the backbone could be as active as with Case 1, requiring a separate and centralized routing backbone. Case 4. Multi-homed organizations, whether or not requiring interorganizational interoperability, have a unique position with respect to NSAP assignment and the use of routing backbones [1]. One option is for the organization to derive its NSAP address space from a dominant TRD as a backbone, and to have other domains advertise accessibility to the organization. This method provides for organizationally unique address prefixes and allows mobility without necessarily changing addresses. - Ownership/control of network components The Numbered Air Forces each control the communications assets within their areas of responsibility. Other organizations within DoD have similar levels of communications asset control. These organizations will have corresponding levels of administrative responsibility over these assets; for example, certain organizations will be registration authorities for naming and addressing. Thus, NSAP address assignment responsibilities nust be defined according to some level of control over assets. - Shared management of network components The components of interest here are routing servers and routing data base servers. These functions are generally performed by the same processing component. Sharing management of the routing servers may lead to a "boundary of control" issue. Administrative agreements among the sharing organizations will consider a) use of routing domains as transits, b) allocation of functionality, c) guaranteed resource utilization levels, d) cost determination, e) architectural control, f) operational control and coordination, etc. - Hierarchical network architectures Within specific geographic areas an administration will have various levels of control over the architecture of an OSI routing domain or a TCP/IP subnetwork. The geographic areas may be a site, metropolitan area, or larger region. A hierarchy independent of geography may exist if an administration establishes an architectural concept for an enterprise system. It is noted that IDRP supports hierarchical inter-domain routing [4]. A flat or deep hierarchical architecture might develop in either the geographic or non-geographic case. In other words, there could be either many small routers or few large routers. At least the following issues will arise in both cases: location of the routing function, routing efficiency, routing policy, interoperability among the routers, permanence of connections, adaptability to future technologies, etc. - Geographical vs Enterprise addresses Geographic- and enterprise-oriented architectures have different addressing needs. A geographic architecture contains topological routing significance in the address. An enterprise architecture contains an organizational identity in the address, independent of routing significance. The issues include end system mobility (a tactical system concern), maintenance of routing tables, location of routing intelligence. Clarification. This paper equates geographic architectures with the topology of the network's access points or intermediate systems. Another interpretation of the term "geography" is to associate it with the geographic location of the end system, while making no assumption about the end system's geographic association of the intermediate system. This paper's discussion presumes that such an end system geography is equivalent to the enterprise architecture in which the enterprise's NSAP rather than geography is significant. A resulting "mesh addressing structure" can be avoided as defined in case 4 above. - Routing Data abstraction Routing Data abstraction refers to address formats which contain routing significance. For example, "smith.fairfax.va.us" (a geographic format) allows a router to determine a most likely efficient path, "smith.sna.fedsys.ibm" (an enterprise address) supports certain policy decisions rather than routing efficiency. Such architectural choices can be supported by the appropriate level of abstraction. - Ease of implementing an OSI network with relatively immature software Available OSI software products do not contain the flexibility of the more mature IP products. Therefor, choice of address semantics should consider ease of configuration at this time. This will also help to encourage experimentation with the OSI products in the DoD community. As the DoD gains knowledge during the experimentation, a better and perhaps more complex address semantic may be adopted. Future product flexibility may then accomodate more complex address semantics. - Appropriate use of the IS-IS and IDRP protocols Background. There are four types of hierarchical routing protocols in OSI. They are: Reference Common Terminology ISO9542 (CLNP) ES-IS DIS10589 Intra-Domain IS-IS Level 1 DIS10589 Intra-Domain IS-IS Level 2 ECMA TR/50 Inter-Domain IS-IS (or Inter-Domain Routing Protocol (IDRP) ES-IS is not relevant to the current discussion. The DIS10589 protocols are sensitive to paths' time delays and have a complete topological knowledge of their routing domain through a flooding technique. IDRP is sensitive only to hop count, not temporal conditions such as caused by congestion or line errors. IDRP's use of the distance vector algorithm causes scaling problems with the reachibility database [3]. IDRP algorithms thus seems to have advantages over intra-domain IS-IS algorithms when the network carries less time sensitive traffic in a simpler topology with fewer reconfigurations. A conservative number of intra-domain IS-IS nodes engaged in flooding routing information may be appropriate since there are few cases known by this author of successful large networks using this technique except for the MILNET upon which to base an assessment. - Protocol availability IS-IS was recently announced by DEC; cisco incorporates the OSI architecture (domains and areas) but currently uses the proprietary IGRP for IS-IS. IDRP is expected to become an international standard in about a year; proprietary protocols and static tables will suffice until its availability. - Policy Routing and NSAP RD Allocation (to be written) 4. Alternatives There are several alternative architectures the routers could support. a. Individual sites (such as an AF base) could be routing domains. b. A service or agency could be a routing domain. c. DoD could have a common backbone routing domain. d. Geographical regions could be routing domains. e. Geographically dispersed enterprise systems could be routing domains. f. S/As could have their own backbone routing domain. g. S/As could acquire/use their own AAIs for topological significance. h. Various combinations of the above are possible. 5. Recommendation 5.1. Recommended Architecture The services and agencies (S/A) are encouraged to establish routing domains (RD) in a backbone and hierarchical arrangement. The S/As may request RDs from a 4K allocation space each. Information Systems (IS) may request RDs from a 4K allocation space each. Each service and agency is encouraged to establish one backbone routing domain for service- or agency-wide geographically-based networking. These S/A routing domains will contain areas unique to a site. (Additional routing domain assignments may be appropriate for enterprise systems, heavily populated sites or mobile assets.) The DISA will provide two backbone networks: 1) a router network as an independent routing domain (DISN), and 2) a switched virtual or physical circuit network (MILNET, DCTN, DISN). The intra-service inter-site routers (i.e., level 2 routers within the S/A routing domain) will communicate by tunneling through the router backbone or by acquiring a circuit (permanent virtual or dedicated line) from the circuit backbone. The S/As will interoperate via IDRP or its available equivalent. Choice of which DISA backbone to use will depend upon required throughput and cost efficiency. A hierarchical NSAP derivation for routing abstraction and hierarchically organized RDs are complementary concepts. S/As are encouraged to establish hierarchical RDs below the backbone RD in a geographically-based architecture. These "leaf" RDs may be associated with geographic areas as small as specific sites or with geographic regions as large as a Numbered Air Force or a Navy Fleet. As the DISN backbone RD would provide interoperability services between S/A backbone RDs, so the S/A backbone RDs would provide similar interoperability services between leaf (either regional or site) RDs. The hierarchy's breadth and depth shall be designed to balance network administration, operations and management (AO&M) functions with the subscribers' communications requirements. It is anticipated that reliance upon backbones will diminish as leaf RDs become more directly interconnected. Thus, a hierarchical approach to RD architecture will help encourage a topology in which interconnections can be assigned to the fewer RDs in the upper levels of the hierarchy. This will avoid a proliferation of leaf interconnections which can overburden many facets of administration, operations and management. Also, because of the anticipated interconnection of leaf RDs, it is not deemed necessary for the larger and upper level leaf RDs to derive NSAP allocations from the backbone's prefix. On the other hand, the lower level leaf RDs are encouraged to support routing data abstraction by deriving their NSAPs from the upper level RDs or, depending on topology, the directly connected backbone. Information Systems (IS) desiring an enterprise-oriented addressing scheme shall derive their NSAP addresses from the DISN backbone, or from a S/A backbone as appropriate. The enterprise shall design their areas to suit the requirements of their organization. Intra-enterprise and inter-domain communications shall be established through one of the DISA backbones and/or one of the S/A backbone routing domains as appropriate. 5.2 Recommendation's Advantages The recommended architecture upon which to structure an OSI NSAP semantic has the following advantages: a. Address Space. The S/As each have a large address space from which to allocate domains. Each service may design networks with up to 4096 routing domains and up to 32,768 areas for a total of 128 M subnetworks. b. Tactical Mobility. In addition to the S/A allocation, a block of 4096 RDs is reserved to support tactical information systems (IS) requiring non-realtime end system mobility. Assuming a hierarchically structured RD system, the individualized NSAP space specified here will not cause excessive access advertisement among transit routing domains (TRD) because there will not be many TRDs. c. Enterprise Systems. Enterprise systems, or wide-area information systems (IS), not requiring mobility services will derive their NSAP from the appropriate dominant backbone TRD. This will support organizational uniqueness to a portion of the NSAP and reduce the routing complexity over that involving specific RDs for each IS. d. Interoperability. Backbone RDs provide interoperability among other transit and non-transit RDs. In the initial engineering phases of OSI integration within the Defense Information Systems Network (DISN), backbone RDs will provide a centralized perspective for establishing bandwidth as well as routing efficiencies. The DISN and S/A backbone RDs will also conveniently support geographical and organizational interoperability by providing the necessary AO&M services to their attached RDs and the end subscribers. e. Routing and Policy. Application of both hierarchical RD topologies and hierarchical NSAP derivation strategies will reduce network routing overhead and support policy routing systems. The greatest challenge with designing a policy router is reduce the amount of link state information exchanged between the routers to a minimum. The IETF's Inter-Domain Policy Routing (IDPR) Working Group (IDPRWG) has considered this issue; an evaluation of the IDPR architecture concludes that in the case of a large mesh internet the problem is substantial but that the Internet "will more resemble a tree ... [so] transmission utilization for overhead traffic will not be as severe." [3] Following the hierarchical concepts will thus support IDPR and any link-state routing algorithm. The hierarchical model should also improve distance-vector implementations of policy routing by limiting the potential number of transit RDs. 5.3 Recommended DoD NSAP Semantics and Assignment Concept The Defense Information Systems Agency (DISA), as the DoD Administrative Authority (AA) for GOSIP, shall request the General Services Administration (GSA), as the NSAP DSP Administrator, to assign one AA Identifier (AAI) to the DoD. Under this AAI, DISA will allocate other fields (see Table 1) in the GOSIP 2 NSAP depicted here: IDP AFI IDI DSP DFI AA Rsvd RD Area ID Sel 47 5 80h zzzzzz xxxx rrrr aaaa ssssssssssss nn The DISA Registration Authority (RA), through the Network Information Center (NIC), shall maintain records of all AA, RD, and Area assignments. The RA shall maintain records of all DISA backbone ID assignments. All organizations accepting responsibility for RD administration shall maintain records of their subdomain's ID assignments. See [2] for further details. The AA shall assign RD values for all systems using DoD long-haul transit routing domains (TRDs); that is, a "DISA backbone" as defined above. Each routing domain identified in Table 1 is potentially a TRD. Thus the RD possesses administrative and topological significance. Agreements supporting a hierarchical routing data base structure applied to these RDs will encourage optimum routing data abstraction as identified in [1]. The AA further requires that all DoD RDs acquiring non-DoD TRD service shall: a. acquire a single address prefix based upon its connection to a DoD TRD service, and b. establish agreement with the non-DoD TRDs that those TRDs shall "maintain in their own routing tables a routing entry for MBII, but be extremely selective in terms of which other backbones and regionals are told of this route" [1]. The AA will delegate responsibility for assignment of Area and ID values to the Routing Domain Authority. The RD Authority shall either be DISA (for the special case of an End System which must acquire routing services from the DISN router backbone), or the Service or Agency authority requesting a routing domain assignment. References. [1] Richard Colella (NIST), Ella Gardner (MITRE) and Ross Callos (DEC). Guidelines for OSI NSAP Allocation in the Internet. Internet Draft, Network Working Group, 1 March 1991. [2] William Barns (MITRE). OSI Network Addresses for the DoD Internet. Draft Version 4, 23 January 1991. [3] Inter-Domain Policy Routing Architecture Assessment Report. SAIC (Contract No. DCA100-89-C0001, Subcontract No. 89-160), April 1991. [4] Yakov Rekhter (IBM) and Dave Katz (Merit/NSFNET). The Border Gateway Protocol: A Pragmatic Approach to Inter-Autonomous System Routing. ConnecXions, Volume 5, No. 1, January 1991 Table 1: DoD Domains and Subdomains Routing Domain RD Area ID SEL rrrr aaaa ssssssssssss nn DISN Backbone 0000 Note 1/2 Note 2 Note 3 Army Backbone 1000 " " " Navy Backbone 2000 " " " Air Force Backbone 3000 " " " Marine Corp Backbone 4000 " " " Agency Backbones 5000 " " " IS Backbones, Note 4 6xxx " " " Following offered for X.121 or IP Encapsulation, Note 2 DDN-Direct-Connect 0F00 Net Mgmt Hosts 0001 General Hosts 0002 Special Hosts 0003 Encapsulated X.121 X.121, right justified, binary, 2**15=0 Encapsulated IP IP, right justified, 2**15=1 Non-DDN-Direct-Connect xxxx Encapsulated X.121 2**15=1 X.121, right justified, binary, 2**15=0 Encapsulated IP 2**15=1 IP, right justified, 2**15=1 Other 2**15=0 MAC, other Note 1: All DoD Areas shall derive their assignments from the routing domain administrator. No Area shall be homed to more than one routing domain. Note 2: All DoD End Systems shall derive their assignments from the routing domain administrator. No ID shall be homed to more than one Area. The DDN-Direct-Connect and Non-DDN-Direct-Connect formats above are offered to simplify assignment when it is desired to show a relationship between an end system and either the MILNET or an IP Internet address space. Note 3: The SEL field assignments shall conform to GOSIP standards. Note 4: RD semantics and assignments for the IS backbones have yet to be defined.